![[Amazon FSx for NetApp ONTAP] ボリュームを間違って削除した時にありがたいボリュームリカバリーキューの紹介](https://devio2023-media.developers.io/wp-content/uploads/2022/08/amazon-fsx-for-netapp-ontap.png)
[Amazon FSx for NetApp ONTAP] ボリュームを間違って削除した時にありがたいボリュームリカバリーキューの紹介
ボリューム削除時にはボリュームリカバリーキューを意識しよう
げげげっ! ボリュームを間違えて削除してしまった!
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSx for ONTAP)のボリュームを間違えて削除してしまったことはありますか? 私はありません。しかし、今後しでかしそうな予感がしています。
というのもFSx for ONTAPのボリュームには削除保護がありません。
マネジメントコンソールからボリュームを削除しようとすると、以下のようにボリュームを本当に削除しても良いか確認が入ります。
しかし、AWS CLIから削除しようとすると、すんなり削除の処理が走ります。(オプションを指定しない場合、削除前にバックアップの処理が走ります)
# ボリュームの削除
$ aws fsx delete-volume --volume-id fsvol-06bed1a4386995178
{
"VolumeId": "fsvol-06bed1a4386995178",
"Lifecycle": "DELETING"
}
# ボリュームのステータスの確認
$ aws fsx describe-volumes --volume-id fsvol-06bed1a4386995178
{
"Volumes": [
{
"CreationTime": "2023-02-12T09:05:31.824000+00:00",
"FileSystemId": "fs-05f72eb8f8d03c709",
"Lifecycle": "DELETING",
"Name": "vol_timezone",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/vol_timezone",
"SecurityStyle": "UNIX",
"SizeInMegabytes": 128,
"StorageEfficiencyEnabled": false,
"StorageVirtualMachineId": "svm-0404cd705c847e961",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"Name": "NONE"
},
"UUID": "6d9092cb-aab4-11ed-946a-5191ab1a5297",
"OntapVolumeType": "RW",
"SnapshotPolicy": "timezone-test",
"CopyTagsToBackups": false
},
"ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-05f72eb8f8d03c709/fsvol-06bed1a4386995178",
"VolumeId": "fsvol-06bed1a4386995178",
"VolumeType": "ONTAP"
}
]
}
# ボリュームが削除されたことを確認
$ aws fsx describe-volumes --volume-id fsvol-06bed1a4386995178
An error occurred (VolumeNotFound) when calling the DescribeVolumes operation: Volume 'fsvol-06bed1a4386995178' does not exist.
そのため、ボリュームIDのコピペミスなどをすると大惨事になりやすいです。
バックアップも取っていなければ諦めるしかないのか...
そんなことはありません。ONTAPにはボリュームリカバリーキューというありがたい機能が存在します。
以降、ボリュームリカバリーキューの紹介をします。
いきなりまとめ
- ボリュームリカバリーキューとはボリュームタイプが RW または DP のボリュームを削除した場合、そのボリュームを部分的に削除された状態にする機能
- デフォルトではボリュームは一定時間(デフォルトは12時間)リカバリキューに保持されたあと、完全に削除される
- リカバリーキュー内に保存されている期間であればボリュームを復旧させることが可能
- Snapshotも保持される
- リカバリーキュー内に保存されている期間はそのボリュームが残るためスペースを消費する
- ボリュームの削除目的がSSDの空き容量確保であれば、ボリュームリカバリーキューからボリュームを完全に削除する必要がある
- ボリュームを削除すると以下の情報が削除されるためリカバリーキューからリカバリーした場合は再設定する必要がある
- ジャンクションマッピング
- LUN マッピング
- Snapshot policy
- Export policy
- QoS policy
- quota policy rules
- リカバリーしたボリュームをオンラインにすると同じAggregate内の全てのボリュームのパフォーマンスが一時的に低下することがある
- 大量にボリュームをリカバリーして、一気にオンラインするというのは避けた方が良い
- リカバリーしてもStorage Efficiencyによるデータ削減量は維持される
- リカバリーしても階層化は維持される
- リカバリーするタイミングでキャパシティプールストレージ上のデータがSSDに書き戻される事象は発生しない
- リカバリーするとStorage Efficiencyの優先度が低くなることがあるかも
- 優先度が低い場合は自動バックグラウンド重複排除の対象でなくなる
- volume efficiency promoteで優先度を上げることで対応する
- リカバリーキューの保持期間をデフォルトの12時間から変更することも可能
- ただし、変更には権限レベルが
diagnosticである必要 diagnosticNetAppのサポートがない限り使用してはいけない- 既にリカバリーキュー内にあるボリュームには影響を与えない
- volume-delete-retention-hoursを0に指定すると、リカバリーキューに保持されず、即座にボリュームが削除される
- ただし、変更には権限レベルが
- ボリューム削除時に
-forceを指定するとリカバリーキューに保持されず削除される - FlexGroupボリュームもリカバリーキューからリカバリー可能
ボリュームリカバリーキューとは
ボリュームリカバリーキューとはボリュームタイプが RW または DP のボリュームを削除した場合、そのボリュームを部分的に削除された状態にする機能です。
デフォルトではボリュームは一定時間(デフォルトは12時間)リカバリキューに保持されたあと、完全に削除されます。 リカバリーキュー内に保存されている期間であればボリュームを復旧させることが可能です。
裏を返せば、リカバリーキュー内に保存されている期間はそのボリュームが残るためスペースを消費します。
リカバリキュー内で使用されているアグリゲートスペース
リカバリキュー内のボリュームは、引き続きアグリゲートスペースを消費します。アグリゲートスペースを消費'volume show-footprint'しているボリュームについて混乱を避けるため、コマンドの出力には、すべての権限レベルで部分的に削除されたボリュームが含まれます。
そのため、「ボリュームを削除してSSDの空きを確保したい」といったときは注意が必要です。
なお、ボリュームを削除すると以下の情報がボリュームから削除されるので、リカバリーする場合は別途設定し直す必要があります。
- ジャンクションマッピング
- LUN マッピング
- Snapshot policy
- Export policy
- QoS policy
- quota policy rules
また、ボリュームの名前がボリューム名_DSIDに変更されます。
やってみた
テスト用ファイルの作成
ボリュームリカバリーキューを試してみましょう。
せっかくなのでボリューム内にファイルを作成して、リカバリーした際もそのファイルを保持していることを確認します。
前準備としてvol_recovery_testというボリュームを作成します。
# ボリュームの作成 ::> volume create -vserver SVM -volume vol_recovery_test -aggregate aggr1 -size 16GB -state online -policy default -tiering-policy none -junction-path /vol_recovery_test [Job 1338] Job succeeded: Successful # ボリュームが作成されたことを確認 ::> volume show -vserver SVM -volume vol_recovery_test -fields state, type, size, available, used, junction-path vserver volume size state junction-path available used type ------- ----------------- ---- ------ ------------------ --------- ----- ---- SVM vol_recovery_test 16GB online /vol_recovery_test 15.20GB 340KB RW
ボリューム作成後、現在のSSDの空き容量と、SSDとキャパシティプールストレージの使用量を確認しておきます。
# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
Available
Vserver Aggregate State Size Type SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM aggr1 online 808.3GB ssd non-snaplock
::> vserver show-aggregates -vserver SVM -instance
Vserver: SVM
Aggregate: aggr1
State: online
Available Size: 808.3GB
Aggregate Type: ssd
Snaplock Type: non-snaplock
Is NVE Capable: false
# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 52.18GB 6%
Aggregate Metadata 1.30GB 0%
Snapshot Reserve 45.36GB 5%
Total Used 98.84GB 11%
Total Physical Used 56.31GB 6%
Total Provisioned Space 100.1TB
11301%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 867.6MB -
Logical Referenced Capacity 867.6MB -
Logical Unreferenced Capacity 0B -
Total Physical Used 867.6MB -
2 entries were displayed.
NFSクライアントから作成したボリュームをマウントして10GiBのファイルを作成します。
# マウントポイントの作成 $ sudo mkdir -p /mnt/fsxn/vol_recovery_test # ボリュームのマウント $ sudo mount -t nfs svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test /mnt/fsxn/vol_recovery_test/ # マウントされているか確認 $ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test nfs4 16G 320K 16G 1% /mnt/fsxn/vol_recovery_test # 10GiBのファイルの作成 $ sudo dd if=/dev/urandom of=/mnt/fsxn/vol_recovery_test/test-file bs=512M count=20 20+0 records in 20+0 records out 10737418240 bytes (11 GB) copied, 82.7229 s, 130 MB/s # ファイル作成後のボリュームの空き容量の確認 $ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test nfs4 16G 11G 5.1G 67% /mnt/fsxn/vol_recovery_test
ファイル作成後、ONTAP CLIからもSSDの空き容量と使用量を確認します。
# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
Available
Vserver Aggregate State Size Type SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM aggr1 online 798.2GB ssd non-snaplock
# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 62.29GB 7%
Aggregate Metadata 1.31GB 0%
Snapshot Reserve 45.36GB 5%
Total Used 109.0GB 12%
Total Physical Used 66.56GB 7%
Total Provisioned Space 100.1TB
11301%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 867.6MB -
Logical Referenced Capacity 867.6MB -
Logical Unreferenced Capacity 0B -
Total Physical Used 867.6MB -
2 entries were displayed.
ファイル作成前と比較して、確かにSSDが10GiB分消費されていますね。
ボリュームの削除
それではボリュームの削除をします。
ふと、Snapshotはリカバリキューからリカバリーした場合も残るのか気になったので、事前にSnapshotを取得します。
# Snapshotの取得
::> snapshot create -vserver SVM -volume vol_recovery_test -snapshot recovery_test
# 取得したSnapshotの確認
::> snapshot show -vserver SVM -volume vol_recovery_test
---Blocks---
Vserver Volume Snapshot Size Total% Used%
-------- -------- ------------------------------------- -------- ------ -----
SVM vol_recovery_test
recovery_test 144KB 0% 0%
ボリュームを削除します。
# ボリュームをオフラインに変更
::> volume offline -vserver SVM -volume vol_recovery_test
Warning: Volume "vol_recovery_test" on Vserver "SVM" must be unmounted before being taken offline or restricted.
Clients will not be able to access the affected volume and related junction paths after that. Do you still
want to unmount the volume and continue? {y|n}: y
Volume "SVM:vol_recovery_test" is now offline.
# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test
Info: Volume "vol_recovery_test" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
The space used by the volume will be recovered only after the retention period of 12 hours has completed. To
recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
vol_recovery_test_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
<volume_name>" command.
Warning: Are you sure you want to delete volume "vol_recovery_test" in Vserver "SVM" ? {y|n}: y
[Job 1341] Job succeeded: Successful
# ボリュームが削除されたことを確認
::> volume show -vserver SVM -volume vol_recovery_test -fields state, type, size, available, used, junction-path
There are no entries matching your query.
# 削除したボリュームのSnapshotを認識できないことを確認
::> snapshot show -vserver SVM -volume vol_recovery_test
There are no entries matching your query.
ボリュームを削除後、SSDの空き容量と使用量を確認します。
# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
Available
Vserver Aggregate State Size Type SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM aggr1 online 798.2GB ssd non-snaplock
# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 62.30GB 7%
Aggregate Metadata 1.31GB 0%
Snapshot Reserve 45.36GB 5%
Total Used 109.0GB 12%
Total Physical Used 66.59GB 7%
Total Provisioned Space 100.1TB
11301%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 867.6MB -
Logical Referenced Capacity 867.6MB -
Logical Unreferenced Capacity 0B -
Total Physical Used 867.6MB -
2 entries were displayed.
ボリュームを削除しましたが、SSDの使用量は変わっていませんね。
ボリュームのリカバリー
ボリュームリカバリーキューから削除したボリュームをリカバリーします。
ボリュームリカバリーキューの操作は権限レベルがadvanced以上である必要があります。
# admin では recovery-queue がない
::> volume ?
analytics> The analytics directory
autosize Set/Display the autosize settings of the flexible volume.
clone> Manage FlexClones
create Create a new volume
delete Delete an existing volume
efficiency> Manage volume efficiency
encryption> The encryption directory
expand Expand the size of a volume by adding constituents
file> File related commands
flexcache> Manage FlexCache
modify Modify volume attributes
mount Mount a volume on another volume with a junction-path
offline Take an existing volume offline
online Bring an existing volume online
qtree> Manage qtrees
quota> Manage Quotas, Policies, Rules and Reports
reallocation> Commands for measuring and optimizing data layout
rehost Rehost a volume from one Vserver into another Vserver
rename Rename an existing volume
restrict Restrict an existing volume
show Display a list of volumes
show-footprint Display a list of volumes and their data and metadata footprints in their associated
aggregate.
show-space Display space usage for volume(s)
size Set/Display the size of the volume.
snaplock> Manages SnapLock attributes of a SnapLock volume
snapshot> Manage snapshots
unmount Unmount a volume
# 権限レベルを advanced に変更
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
# recovery-queue が存在することを確認
::*> volume ?
analytics> The analytics directory
autosize Set/Display the autosize settings of the flexible volume.
clone> Manage FlexClones
conversion> *The conversion directory
create Create a new volume
delete Delete an existing volume
efficiency> Manage volume efficiency
encryption> The encryption directory
expand Expand the size of a volume by adding constituents
file> File related commands
flexcache> Manage FlexCache
flexgroup> *Manage FlexGroup operations
make-vsroot *Designate a non-root volume as a root volume of the Vserver
modify Modify volume attributes
mount Mount a volume on another volume with a junction-path
offline Take an existing volume offline
online Bring an existing volume online
qtree> Manage qtrees
quota> Manage Quotas, Policies, Rules and Reports
reallocation> Commands for measuring and optimizing data layout
recovery-queue> *Manage volume recovery queue
rehost Rehost a volume from one Vserver into another Vserver
rename Rename an existing volume
restrict Restrict an existing volume
show Display a list of volumes
show-footprint Display a list of volumes and their data and metadata footprints in their associated
aggregate.
show-space Display space usage for volume(s)
size Set/Display the size of the volume.
snaplock> Manages SnapLock attributes of a SnapLock volume
snapshot> Manage snapshots
unmount Unmount a volume
::*> volume recovery-queue ?
modify *Modify attributes of volumes in the recovery queue
purge *Purge volumes from the recovery queue belonging to a Vserver
purge-all *Purge all volumes from the recovery queue belonging to a Vserver
recover *Recover volumes from the recovery queue belonging to a Vserver
recover-all *Recover all volumes from the recovery queue belonging to a Vserver
show *Show volumes in the recovery queue
移行は権限レベルをadvancedにして作業をします。
ボリュームリカバリーキューに削除したボリュームがあるか確認します。
# ボリュームリカバリーキューの確認
::*> volume recovery-queue show
Vserver Volume Deletion Request Time Retention Hours
--------- ----------- ------------------------ ---------------
SVM vol_recovery_test_1098
Fri Mar 31 13:51:38 2023 12
::*> volume recovery-queue show -instance
Vserver Name: SVM
Volume Name: vol_recovery_test_1098
Deletion Request Time: Fri Mar 31 13:51:38 2023
Volume Delete Retention: 12
Volume Instance UUID: e63103cd-cf7b-11ed-b946-e1cdfb9c8ff0
ありましたね。こちらのボリュームをvolume recovery-queue recoverでリカバリーします。
# ボリュームリカバリーキュー内のボリュームのリカバリー
::*> volume recovery-queue recover -vserver SVM -volume vol_recovery_test_1098
Notice: When you bring a recovered volume online, there may be a temporary drop in performance for all volumes in the same aggregate.
Volume recovery successful for volume "vol_recovery_test_1098" in Vserver "SVM".
# リカバリーしたボリュームの確認
::*> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume size state junction-path available used type
------- ---------------------- ---- ------- ------------- --------- ---- ----
SVM vol_recovery_test_1098 16GB offline - - - RW
# リカバリーしたボリュームのSnapshotの確認
::*> snapshot show -vserver SVM -volume vol_recovery_test*
There are no entries matching your query.
Info: Unable to get information for Snapshot copies of volume "vol_recovery_test_1098" on Vserver "SVM". Reason: Volume
not online.
ボリュームがリカバリーされましたね。
ただし、ボリューム名がリカバリーキュー内の時のままになっていたり、オフライン状態になっていたりします。
NetAppのKBにもリカバリー後に行う処理として紹介されています。
Post recovery steps:
After using the recover command, the following steps must still be performed on the volume:
- Rename the volume using volume rename command.
- Set up a junction, if required, running the volume mount command.
- Create mappings for LUNs in the volume, if required, run the lun map command.
- Associate a snapshot policy, an export policy with the volume, if required, with the volume modify command.
- Add new quota policy rules for the volume, if required, with the quota policy rule command.
- Add a QOS policy for the volume, if required, run the volume modify command.
Note: When you bring a recovered volume online, there might be a temporary drop in performance for all volumes in the same aggregate.
How to use the Volume Recovery Queue - NetApp Knowledge Base
必要に応じて設定をしましょう。
また、注意書きの通り、リカバリーしたボリュームをオンラインにすると同じAggregate内の全てのボリュームのパフォーマンスが一時的に低下することがあるようです。大量にボリュームをリカバリーして、一気にオンラインするというのは避けた方が良いかもしれません。
ボリュームの名前の変更や、オンライン状態への変更、ジャンクションパスへのマウントをします。
# 権限レベルを admin に戻す
::*> set admin
# ボリューム名を変更
::> volume rename -vserver SVM -volume vol_recovery_test_1098 -newname vol_recovery_test
[Job 1343] Job is queued: Rename vol_recovery_test_1098 to vol_recovery_test.
[Job 1343] Job succeeded: Successful
# ボリューム名が変更された子を確認
::> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume size state junction-path available used type
------- ----------------- ---- ------- ------------- --------- ---- ----
SVM vol_recovery_test 16GB offline - - - RW
# ボリュームをオンラインに
::> volume online -vserver SVM -volume vol_recovery_test
Volume "SVM:vol_recovery_test" is now online.
# ボリュームがオンラインになったことを確認
::> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume size state junction-path available used type
------- ----------------- ---- ------ ------------- --------- ------- ----
SVM vol_recovery_test 16GB online - 5.10GB 10.10GB RW
# Snapshotを認識できるようになったことを確認
::> snapshot show -vserver SVM -volume vol_recovery_test
---Blocks---
Vserver Volume Snapshot Size Total% Used%
-------- -------- ------------------------------------- -------- ------ -----
SVM vol_recovery_test
recovery_test 400KB 0% 0%
# ジャンクションパスへのマウント
::> volume mount -vserver SVM -volume vol_recovery_test -junction-path /vol_recovery_test
# マウントできたことを確認
::> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume size state junction-path available used type
------- ----------------- ---- ------ ------------------ --------- ------- ----
SVM vol_recovery_test 16GB online /vol_recovery_test 5.10GB 10.10GB RW
特に詰まることなく各設定変更ができました。また、ボリュームをオンラインにすることでSnapshotを認識できるようになりましたね。
NFSクライアントからリカバリーしたボリューム内のファイルを認識できることを確認します。
# マウントできていることを確認 $ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test nfs4 16G 11G 5.1G 67% /mnt/fsxn/vol_recovery_test # ボリューム内にファイルがあることを確認 $ ls -l /mnt/fsxn/vol_recovery_test/ total 10527052 -rw-r--r-- 1 root root 10737418240 Mar 31 04:39 test-file # Snapshot ディレクトリにもアクセスできることを確認 $ ls -lR /mnt/fsxn/vol_recovery_test/.snapshot /mnt/fsxn/vol_recovery_test/.snapshot: total 4 drwxr-xr-x 2 root root 4096 Mar 31 04:37 recovery_test /mnt/fsxn/vol_recovery_test/.snapshot/recovery_test: total 10527052 -rw-r--r-- 1 root root 10737418240 Mar 31 04:39 test-file
ボリューム内のファイル、Snapshotディレクトリ内のファイルどちらも認識できましたね。
なお、ボリュームリカバリー後の、SSDの空き容量と使用量を確認しましたが、目立った変化はありませんでした。
# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
Available
Vserver Aggregate State Size Type SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM aggr1 online 798.2GB ssd non-snaplock
# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 62.30GB 7%
Aggregate Metadata 1.31GB 0%
Snapshot Reserve 45.36GB 5%
Total Used 109.0GB 12%
Total Physical Used 66.67GB 7%
Total Provisioned Space 100.1TB
11301%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 867.6MB -
Logical Referenced Capacity 867.6MB -
Logical Unreferenced Capacity 0B -
Total Physical Used 867.6MB -
2 entries were displayed.
ボリュームリカバリーキューからリカバリーしてもStorage Efficiencyによるデータ削減量は維持されるのか
テスト用ファイルの作成
ボリュームリカバリーキューからリカバリーしてもStorage Efficiencyによるデータ削減量は維持されるのか気になってきました。
現在はStorage Efficiencyは有効化していますが、重複排除・圧縮は効いていません。
# Storage Efficiencyが有効化されているか確認
::> volume efficiency show -vserver SVM -volume vol_recovery_test
Vserver Name: SVM
Volume Name: vol_recovery_test
Volume Path: /vol/vol_recovery_test
State: Enabled
Status: Idle
Progress: Idle for 00:48:13
Type: Regular
Schedule: -
Efficiency Policy Name: auto
Blocks Skipped Sharing: 0
Last Operation State: Success
Last Success Operation Begin: Fri Mar 31 13:39:21 2023
Last Success Operation End: Fri Mar 31 13:39:28 2023
Last Operation Begin: Fri Mar 31 13:39:21 2023
Last Operation End: Fri Mar 31 13:39:28 2023
Last Operation Size: 2.00GB
Last Operation Error: -
Changelog Usage: 0%
Logical Data Size: 10.10GB
Logical Data Limit: 640TB
Logical Data Percent: 0%
Queued Job: -
Stale Fingerprint Percentage: 0
Compression: false
Inline Compression: true
Storage Efficiency Mode: efficient
Constituent Volume: false
Inline Dedupe: true
Data Compaction: true
Cross Volume Inline Deduplication: false
Cross Volume Background Deduplication: false
Extended Compressed Data: true
# 重複排除・圧縮量を確認
# (TSSEのボリュームの圧縮の効果はAggregateレベルで確認する必要があるため、compression-space-save や compression-space-saved-percent は必ず0になる)
::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared, compression-space-saved, compression-space-saved-percent
vserver volume available total used percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared compression-space-saved compression-space-saved-percent
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- ------------------- ----------------------- -------------------------------
SVM vol_recovery_test 5.10GB 15.20GB 10.10GB 66% 0B 0% 0B 0% 0B 0B 0%
もし、維持されない場合ボリュームをリカバリーしたタイミングでSSDが溢れてしまうなんてことが起きてしまいそうです。
実際に確認してみましょう。
検証用に0埋めされた5GiBのファイルを作成します。
# テスト用ファイルの追加 $ sudo dd if=/dev/zero of=/mnt/fsxn/vol_recovery_test/zero_block_file bs=512MB count=10 10+0 records in 10+0 records out 5120000000 bytes (5.1 GB) copied, 33.3181 s, 154 MB/s # ボリュームの使用量の確認 $ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test nfs4 16G 14G 2.0G 87% /mnt/fsxn/vol_recovery_test
なんだか思ったより削減されていませんね。
ONTAP CLIからも確認します。
::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared, compression-space-saved, compression-space-saved-percent vserver volume available total used percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared compression-space-saved compression-space-saved-percent ------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- ------------------- ----------------------- ------------------------------- SVM vol_recovery_test 2.11GB 15.20GB 13.09GB 86% 1.76GB 12% 1.76GB 12% 60KB 0B 0%
1.76GBしか重複排除により削減されていませんでした。
全て0で埋められたデータであるため、重複排除量は5GiBであって欲しいところです。
試しに手動でStorage Efficiencyをかけてみます。
::> volume efficiency start -vserver SVM -volume vol_recovery_test
Error: command failed: Failed to start efficiency on volume "vol_recovery_test" of Vserver "SVM": Cannot perform
efficiency operations on deprioritized volume. To be able to perform efficiency operations, run the (privilege:
advanced) "volume efficiency promote" command first.
Storage Efficiencyの優先度が低くなっているようですね。これもリカバリーキューからリカバリーした影響でしょうか。
同じパラメーターのボリュームを用意して、そのボリュームに同じようにテストファイルを作成し、重複排除が効いているか確認します。
# ボリュームの作成 ::> volume create -vserver SVM -volume vol_recovery_test_2 -aggregate aggr1 -size 16GB -state online -policy default -tiering-policy none -junction-path /vol_recovery_test_2 [Job 1345] Job succeeded: Successful # ボリュームが作成されたことを確認 ::> volume show -vserver SVM -volume vol_recovery_test_2 -fields state, type, size, available, used, junction-path vserver volume size state junction-path available used type ------- ------------------- ---- ------ -------------------- --------- ----- ---- SVM vol_recovery_test_2 16GB online /vol_recovery_test_2 15.20GB 296KB RW
テスト用ファイルを追加します。
# テスト用ファイルの追加 $ sudo dd if=/dev/urandom of=/mnt/fsxn/vol_recovery_test_2/test-file bs=512M count=20 20+0 records in 20+0 records out 10737418240 bytes (11 GB) copied, 81.7745 s, 131 MB/s $ sudo dd if=/dev/zero of=/mnt/fsxn/vol_recovery_test_2/zero_block_file bs=512MB count=10 10+0 records in 10+0 records out 5120000000 bytes (5.1 GB) copied, 33.3641 s, 153 MB/s # ボリュームの使用量の確認 $ df -hT -t nfs4 | grep _2 svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test_2 nfs4 16G 11G 5.1G 67% /mnt/fsxn/vol_recovery_test_2
リカバリーしたボリュームと比較して使用量が3GBほど差が出ていますね。
ONTAP CLIからも確認します。
::> volume show -volume vol_recovery_test_2 -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume available total used percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ------------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM vol_recovery_test_2 5.08GB 15.20GB 10.12GB 66% 4.77GB 32% 4.77GB 32% 0B
::> volume efficiency show -vserver SVM -volume vol_recovery_test_2
Vserver Name: SVM
Volume Name: vol_recovery_test_2
Volume Path: /vol/vol_recovery_test_2
State: Enabled
Status: Idle
Progress: Idle for 00:08:19
Type: Regular
Schedule: -
Efficiency Policy Name: auto
Blocks Skipped Sharing: 0
Last Operation State: Success
Last Success Operation Begin: Fri Mar 31 16:20:17 2023
Last Success Operation End: Fri Mar 31 16:20:25 2023
Last Operation Begin: Fri Mar 31 16:20:17 2023
Last Operation End: Fri Mar 31 16:20:25 2023
Last Operation Size: 2.21GB
Last Operation Error: -
Changelog Usage: 0%
Logical Data Size: 14.89GB
Logical Data Limit: 640TB
Logical Data Percent: 0%
Queued Job: -
Stale Fingerprint Percentage: 0
Compression: false
Inline Compression: true
Storage Efficiency Mode: efficient
Constituent Volume: false
Inline Dedupe: true
Data Compaction: true
Cross Volume Inline Deduplication: false
Cross Volume Background Deduplication: false
Extended Compressed Data: true
重複排除により4.77GBほど削減できていました。
そうなると、やはりリカバリーキューからリカバリーした影響が高そうです。
NetAppのKBを確認すると、優先度の低いボリュームは自動バックグラウど重複排除の対象でなくなるようです。
AFF では、自動ポリシーが設定されているすべてのボリュームが監視され、節約量が少ないボリュームや頻繁に上書きされるボリュームの優先順位が解除されます。
- 優先度が下がったボリュームは、自動バックグラウンド重複排除の対象ではなくなります。
- 優先度が下がったボリュームの変更ロギングは無効になり、ボリューム上のメタデータは切り捨てられます。
advanced volume efficiency promote 権限レベルのコマンドを使用すると、優先度が下がったボリュームを昇格させて、自動バックグラウンド重複排除の対象に戻すことができます。
こちらに従い、volume efficiency promoteでボリュームの優先度を上げて自動バックグラウンド重複排除の対象に戻してあげます。
# 権限レベルを advanced に変更
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
# ボリュームの優先度を上げる
::*> volume efficiency promote -vserver SVM -volume vol_recovery_test
Volume "vol_recovery_test" of Vserver "SVM" has been made available for automatic deduplication scheduling.
# Storage Efficiencyの実行
::> volume efficiency start -vserver SVM -volume vol_recovery_test
The efficiency operation for volume "vol_recovery_test" of Vserver "SVM" has started.
# Storage Efficiencyによるデータ削減量の確認
::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume available total used percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM vol_recovery_test 2.11GB 15.20GB 13.09GB 86% 1.76GB 12% 1.76GB 12% 60KB
volume efficiency promoteにより、ボリュームの優先度を上げたことにより、volume efficiency startを受け付けるようになりました。
しかし、待ってもなかなか重複排除が進みません。
NetApp公式ドキュメントを確認すると-scan-old-dataを付与することで既に保存済みのデータブロックに対して重複排除をかけることができそうでした。
You can run the efficiency operations manually on the data that exists in non-temperature sensitive storage efficiency volumes prior to enabling deduplication, data compression, or data compaction with ONTAP versions earlier than ONTAP 9.8. You can run these operations by using the volume efficiency start -scan-old-data command.
実際に試してみます。
# Storage Efficiencyの実行
::> volume efficiency start -vserver SVM -volume vol_recovery_test -scan-old-data
Warning: This operation scans all of the data in volume "vol_recovery_test" of Vserver "SVM". It might take a
significant time, and degrade performance during that time.
Do you want to continue? {y|n}: y
The efficiency operation for volume "vol_recovery_test" of Vserver "SVM" has started.
# Storage Efficiencyの状態の確認
::> volume efficiency show -vserver SVM -volume vol_recovery_test
Vserver Name: SVM
Volume Name: vol_recovery_test
Volume Path: /vol/vol_recovery_test
State: Enabled
Status: Active
Progress: 3221504 KB Scanned
Type: Regular
Schedule: -
Efficiency Policy Name: auto
Blocks Skipped Sharing: 0
Last Operation State: Success
Last Success Operation Begin: Fri Mar 31 15:54:28 2023
Last Success Operation End: Fri Mar 31 15:54:28 2023
Last Operation Begin: Fri Mar 31 15:54:28 2023
Last Operation End: Fri Mar 31 15:54:28 2023
Last Operation Size: 0B
Last Operation Error: -
Changelog Usage: 0%
Logical Data Size: 14.84GB
Logical Data Limit: 640TB
Logical Data Percent: 0%
Queued Job: -
Stale Fingerprint Percentage: 0
Compression: false
Inline Compression: true
Storage Efficiency Mode: efficient
Constituent Volume: false
Inline Dedupe: true
Data Compaction: true
Cross Volume Inline Deduplication: false
Cross Volume Background Deduplication: false
Extended Compressed Data: true
# Storage Efficiecnyによるデータ削減量の確認
::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume available total used percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM vol_recovery_test 2.19GB 15.20GB 13.01GB 85% 1.84GB 12% 1.84GB 12% 64KB
::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume available total used percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM vol_recovery_test 2.48GB 15.20GB 12.71GB 83% 2.16GB 15% 2.16GB 15% 76KB
::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume available total used percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM vol_recovery_test 4.05GB 15.20GB 11.14GB 73% 3.70GB 25% 3.70GB 25% 124KB
# Storage Efficiencyの状態の確認
::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume available total used percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM vol_recovery_test 5.07GB 15.20GB 10.13GB 66% 4.77GB 32% 4.77GB 32% 160KB
::> volume efficiency show -vserver SVM -volume vol_recovery_test
Vserver Name: SVM
Volume Name: vol_recovery_test
Volume Path: /vol/vol_recovery_test
State: Enabled
Status: Idle
Progress: Idle for 00:03:51
Type: Regular
Schedule: -
Efficiency Policy Name: auto
Blocks Skipped Sharing: 0
Last Operation State: Success
Last Success Operation Begin: Fri Mar 31 15:56:44 2023
Last Success Operation End: Fri Mar 31 16:17:11 2023
Last Operation Begin: Fri Mar 31 15:56:44 2023
Last Operation End: Fri Mar 31 16:17:11 2023
Last Operation Size: 14.77GB
Last Operation Error: -
Changelog Usage: 0%
Logical Data Size: 14.91GB
Logical Data Limit: 640TB
Logical Data Percent: 0%
Queued Job: -
Stale Fingerprint Percentage: 0
Compression: false
Inline Compression: true
Storage Efficiency Mode: efficient
Constituent Volume: false
Inline Dedupe: true
Data Compaction: true
Cross Volume Inline Deduplication: false
Cross Volume Background Deduplication: false
Extended Compressed Data: true
すると、ジワジワと重複排除によるデータ削減量が増えていきました。最終的には先に作成したボリュームと同じく4.77GBのデータ量を削減することができました。
ボリュームの削除とリカバリー
手間取りましが、この状態でボリュームの削除とリカバリーを行います。
まず、ボリュームの削除です。
# ボリュームをオフラインに変更
::> volume offline -vserver SVM -volume vol_recovery_test
Warning: Volume "vol_recovery_test" on Vserver "SVM" must be unmounted before being taken offline or restricted.
Clients will not be able to access the affected volume and related junction paths after that. Do you still
want to unmount the volume and continue? {y|n}: y
Volume "SVM:vol_recovery_test" is now offline.
# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test
Info: Volume "vol_recovery_test" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
The space used by the volume will be recovered only after the retention period of 12 hours has completed. To
recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
vol_recovery_test_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
<volume_name>" command.
Warning: Are you sure you want to delete volume "vol_recovery_test" in Vserver "SVM" ? {y|n}: y
[Job 1348] Job succeeded: Successful
# ボリュームが削除されたことを確認
::> volume show -vserver SVM -volume vol_recovery_test -fields state, type, size, available, used, junction-path
There are no entries matching your query.
ボリュームを削除後、SSDの空き容量と使用量を確認します。
# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
Available
Vserver Aggregate State Size Type SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM aggr1 online 787.6GB ssd non-snaplock
# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 72.80GB 8%
Aggregate Metadata 6.88GB 1%
Snapshot Reserve 45.36GB 5%
Total Used 119.5GB 13%
Total Physical Used 68.51GB 8%
Total Provisioned Space 100.1TB
11302%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 867.6MB -
Logical Referenced Capacity 867.6MB -
Logical Unreferenced Capacity 0B -
Total Physical Used 867.6MB -
2 entries were displayed.
10GBのボリュームを追加していることを加味すると、削除後もボリュームの使用量は変わっていないことが分かります。
削除したボリュームをリカバリーキューからリカバリーします。
# 権限レベルを advanced に変更
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
# ボリュームリカバリーキューの確認
::*> volume recovery-queue show
Vserver Volume Deletion Request Time Retention Hours
--------- ----------- ------------------------ ---------------
SVM vol_recovery_test_1098
Fri Mar 31 16:45:58 2023 12
# ボリュームリカバリーキュー内のボリュームのリカバリー
::*> volume recovery-queue recover -vserver SVM -volume vol_recovery_test_1098
Notice: When you bring a recovered volume online, there may be a temporary drop in performance for all volumes in the same aggregate.
Volume recovery successful for volume "vol_recovery_test_1098" in Vserver "SVM".
# リカバリーしたボリュームの確認
::*> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume size state junction-path available used type
------- ---------------------- ---- ------- ------------- --------- ---- ----
SVM vol_recovery_test_1098 16GB offline - - - RW
SVM vol_recovery_test_2 16GB online /vol_recovery_test_2
5.08GB 10.12GB
RW
2 entries were displayed.
# ボリューム名を変更
::*> volume rename -vserver SVM -volume vol_recovery_test_1098 -newname vol_recovery_test
[Job 1350] Job is queued: Rename vol_recovery_test_1098 to vol_recovery_test.
[Job 1350] Job succeeded: Successful
# ボリュームをオンラインに
::*> volume online -vserver SVM -volume vol_recovery_test
Volume "SVM:vol_recovery_test" is now online.
# ジャンクションパスへのマウント
::*> volume mount -vserver SVM -volume vol_recovery_test -junction-path /vol_recovery_test
# リカバリーしたボリュームの確認
::*> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume size state junction-path available used type
------- ----------------- ---- ------ ------------------ --------- ------- ----
SVM vol_recovery_test 16GB online /vol_recovery_test 5.07GB 10.13GB RW
SVM vol_recovery_test_2
16GB online /vol_recovery_test_2
5.08GB 10.12GB RW
2 entries were displayed.
# Storage Efficiencyによるデータ削減量の確認
::*> volume show -volume vol_recovery_test* -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume available total used percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM vol_recovery_test 5.07GB 15.20GB 10.13GB 66% 4.77GB 32% 4.77GB 32% 160KB
SVM vol_recovery_test_2
5.08GB 15.20GB 10.12GB 66% 4.77GB 32% 4.77GB 32% 0B
2 entries were displayed.
リカバリーした場合もStorage Efficiencyによるデータ削減量は維持してくれることが分かりました。
リカバリー後のボリュームがStorage Efficiencyの優先度が下がっているか確認
再度リカバリー後のボリュームがStorage Efficiencyの優先度が下がっているかを確認します。
# Storage Efficiencyの手動実行
::*> volume efficiency start -vserver SVM -volume vol_recovery_test
The efficiency operation for volume "vol_recovery_test" of Vserver "SVM" has started.
# Storage Efficiencyの状態の確認
::*> volume efficiency show -vserver SVM -volume vol_recovery_test
Vserver Name: SVM
Volume Name: vol_recovery_test
Volume Path: /vol/vol_recovery_test
State: Enabled
Status: Idle
Progress: Idle for 00:00:34
Type: Regular
Schedule: -
Efficiency Policy Name: auto
Blocks Skipped Sharing: 0
Last Operation State: Success
Last Success Operation Begin: Fri Mar 31 17:03:24 2023
Last Success Operation End: Fri Mar 31 17:03:24 2023
Last Operation Begin: Fri Mar 31 17:03:24 2023
Last Operation End: Fri Mar 31 17:03:24 2023
Last Operation Size: 0B
Last Operation Error: -
Changelog Usage: 0%
Logical Data Size: 14.89GB
Logical Data Limit: 640TB
Logical Data Percent: 0%
Queued Job: -
Stale Fingerprint Percentage: 0
Compression: false
Inline Compression: true
Compression Type: adaptive
Storage Efficiency Mode: efficient
Constituent Volume: false
Inline Dedupe: true
Data Compaction: true
Cross Volume Inline Deduplication: false
Cross Volume Background Deduplication: false
Extended Compressed Data: true
volume efficiency startできてしまいました。リカバリー後に優先度が下がったのは偶然だったのでしょうか。
階層化ポリシーをAllにしたボリュームのリカバリー
階層化ポリシーの変更
次に階層化ポリシーをAllにしたボリュームをリカバリーした際の挙動を確認します。
リカバリー時にキャパシティプールストレージにあるデータもSSDに一度書き込まれるのか気になりますね。
まず、階層化ポリシーをAllに変更します。
# 現在の階層化ポリシーの確認
::> volume show -vserver SVM -volume vol_recovery_test -fields tiering-policy
vserver volume tiering-policy
------- ----------------- --------------
SVM vol_recovery_test none
# 各階層の使用量の確認
::> volume show-footprint -vserver SVM -volume vol_recovery_test
Vserver: SVM
Volume Name: vol_recovery_test
Volume MSID: 2156877944
Volume DSID: 1098
Vserver UUID: 49892dec-8ccc-11ed-946a-5191ab1a5297
Aggregate Name: aggr1
Aggregate UUID: b7e5d9c9-8ccb-11ed-946a-5191ab1a5297
Hostname: FsxId05f72eb8f8d03c709-01
Tape Backup Metadata Footprint: -
Tape Backup Metadata Footprint Percent: -
Deduplication Footprint: 60.13MB
Deduplication Footprint Percent: 0%
Temporary Deduplication Footprint: -
Temporary Deduplication Footprint Percent: -
Cross Volume Deduplication Footprint: -
Cross Volume Deduplication Footprint Percent: -
Cross Volume Temporary Deduplication Footprint: -
Cross Volume Temporary Deduplication Footprint Percent: -
Volume Data Footprint: 10.18GB
Volume Data Footprint Percent: 1%
Flexible Volume Metadata Footprint: 92.66MB
Flexible Volume Metadata Footprint Percent: 0%
Delayed Free Blocks: 155.0MB
Delayed Free Blocks Percent: 0%
SnapMirror Destination Footprint: -
SnapMirror Destination Footprint Percent: -
Volume Guarantee: 0B
Volume Guarantee Percent: 0%
File Operation Metadata: -
File Operation Metadata Percent: -
Total Footprint: 10.49GB
Total Footprint Percent: 1%
Containing Aggregate Size: 907.1GB
Name for bin0: Performance Tier
Volume Footprint for bin0: 10.34GB
Volume Footprint bin0 Percent: 100%
Name for bin1: FSxFabricpoolObjectStore
Volume Footprint for bin1: 0B
Volume Footprint bin1 Percent: 0%
Total Deduplication Footprint: 60.13MB
Total Deduplication Footprint Percent: 0%
Footprint Data Reduction by Auto Adaptive Compression: 94.41MB
Footprint Data Reduction by Auto Adaptive Compression Percent: 0%
Total Footprint Data Reduction: 94.41MB
Total Footprint Data Reduction Percent: 0%
Effective Total after Footprint Data Reduction: 10.39GB
Effective Total after Footprint Data Reduction Percent: 1%
# 階層化ポリシーをAllに変更
::> volume modify -vserver SVM -volume vol_recovery_test -tiering-policy all
Volume modify successful on volume vol_recovery_test of Vserver SVM.
# 階層化ポリシーがAllになったことを確認
::> volume show -vserver SVM -volume vol_recovery_test -fields tiering-policy
vserver volume tiering-policy
------- ----------------- --------------
SVM vol_recovery_test all
# ほとんどのデータがSSDからキャパシティプールに階層化されたことを確認
::> volume show-footprint -vserver SVM -volume vol_recovery_test
Vserver: SVM
Volume Name: vol_recovery_test
Volume MSID: 2156877944
Volume DSID: 1098
Vserver UUID: 49892dec-8ccc-11ed-946a-5191ab1a5297
Aggregate Name: aggr1
Aggregate UUID: b7e5d9c9-8ccb-11ed-946a-5191ab1a5297
Hostname: FsxId05f72eb8f8d03c709-01
Tape Backup Metadata Footprint: -
Tape Backup Metadata Footprint Percent: -
Deduplication Footprint: 60.13MB
Deduplication Footprint Percent: 0%
Temporary Deduplication Footprint: -
Temporary Deduplication Footprint Percent: -
Cross Volume Deduplication Footprint: -
Cross Volume Deduplication Footprint Percent: -
Cross Volume Temporary Deduplication Footprint: -
Cross Volume Temporary Deduplication Footprint Percent: -
Volume Data Footprint: 10.18GB
Volume Data Footprint Percent: 1%
Flexible Volume Metadata Footprint: 92.66MB
Flexible Volume Metadata Footprint Percent: 0%
Delayed Free Blocks: 159.2MB
Delayed Free Blocks Percent: 0%
SnapMirror Destination Footprint: -
SnapMirror Destination Footprint Percent: -
Volume Guarantee: 0B
Volume Guarantee Percent: 0%
File Operation Metadata: -
File Operation Metadata Percent: -
Total Footprint: 10.49GB
Total Footprint Percent: 1%
Containing Aggregate Size: 907.1GB
Name for bin0: Performance Tier
Volume Footprint for bin0: 348.6MB
Volume Footprint bin0 Percent: 3%
Name for bin1: FSxFabricpoolObjectStore
Volume Footprint for bin1: 10GB
Volume Footprint bin1 Percent: 97%
Total Deduplication Footprint: 60.13MB
Total Deduplication Footprint Percent: 0%
Footprint Data Reduction by Auto Adaptive Compression: 3.11MB
Footprint Data Reduction by Auto Adaptive Compression Percent: 0%
Total Footprint Data Reduction: 3.11MB
Total Footprint Data Reduction Percent: 0%
Effective Total after Footprint Data Reduction: 10.49GB
Effective Total after Footprint Data Reduction Percent: 1%
階層化ポリシーをAllにすることで、10GB分のデータをキャパシティプールストレージに階層化されことを確認できました。
SSDの空き容量や使用量を確認すると、10GB分変動していました。
# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
Available
Vserver Aggregate State Size Type SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM aggr1 online 797.6GB ssd non-snaplock
# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 62.81GB 7%
Aggregate Metadata 1.51GB 0%
Snapshot Reserve 45.36GB 5%
Total Used 109.5GB 12%
Total Physical Used 68.57GB 8%
Total Provisioned Space 100.1TB
11302%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 10.93GB -
Logical Referenced Capacity 10.91GB -
Logical Unreferenced Capacity 21.69MB -
Space Saved by Storage Efficiency 99.22KB -
Total Physical Used 10.93GB -
2 entries were displayed.
ボリュームの削除とリカバリー
この状態でボリュームの削除とリカバリーを行います。
まず、ボリュームの削除です。
# ボリュームをオフラインに変更
::> volume offline -vserver SVM -volume vol_recovery_test
Warning: Volume "vol_recovery_test" on Vserver "SVM" must be unmounted before being taken offline or restricted.
Clients will not be able to access the affected volume and related junction paths after that. Do you still
want to unmount the volume and continue? {y|n}: y
Volume "SVM:vol_recovery_test" is now offline.
# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test
Info: Volume "vol_recovery_test" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
The space used by the volume will be recovered only after the retention period of 12 hours has completed. To
recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
vol_recovery_test_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
<volume_name>" command.
Warning: Are you sure you want to delete volume "vol_recovery_test" in Vserver "SVM" ? {y|n}: y
[Job 1354] Job succeeded: Successful
# ボリュームが削除されたことを確認
::> volume show -vserver SVM -volume vol_recovery_test -fields state, type, size, available, used, junction-path
There are no entries matching your query.
ボリュームを削除後、SSDの空き容量とSSDとキャパシティプールストレージの使用量の確認
# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
Available
Vserver Aggregate State Size Type SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM aggr1 online 797.6GB ssd non-snaplock
# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 62.81GB 7%
Aggregate Metadata 1.51GB 0%
Snapshot Reserve 45.36GB 5%
Total Used 109.5GB 12%
Total Physical Used 68.58GB 8%
Total Provisioned Space 100.1TB
11302%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 10.93GB -
Logical Referenced Capacity 10.91GB -
Logical Unreferenced Capacity 21.69MB -
Space Saved by Storage Efficiency 99.22KB -
Total Physical Used 10.93GB -
2 entries were displayed.
ボリューム削除前後で変わりありませんね。これはリカバリーしても一度SSDに書き込まれるという挙動はしなさそうです。
削除したボリュームをリカバリーキューからリカバリーします。
# 権限レベルを advanced に変更
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
# ボリュームリカバリーキューの確認
::*> volume recovery-queue show
Vserver Volume Deletion Request Time Retention Hours
--------- ----------- ------------------------ ---------------
SVM vol_recovery_test_1098
Fri Mar 31 17:28:04 2023 12
# ボリュームリカバリーキュー内のボリュームのリカバリー
::*> volume recovery-queue recover -vserver SVM -volume vol_recovery_test_1098
Notice: When you bring a recovered volume online, there may be a temporary drop in performance for all volumes in the same aggregate.
Volume recovery successful for volume "vol_recovery_test_1098" in Vserver "SVM".
# 権限レベルを admin に変更
::*> set admin
# ボリューム名を変更
::> volume rename -vserver SVM -volume vol_recovery_test_1098 -newname vol_recovery_test
[Job 1356] Job is queued: Rename vol_recovery_test_1098 to vol_recovery_test. [Job 1356] Job succeeded: Successful
# ボリュームをオンラインに
::> volume online -vserver SVM -volume vol_recovery_test
Volume "SVM:vol_recovery_test" is now online.
# ジャンクションパスへのマウント
::> volume mount -vserver SVM -volume vol_recovery_test -junction-path /vol_recovery_test
# リカバリーしたボリュームの確認
::> volume show -vserver SVM -volume vol_recovery_test -fields state, type, size, available, used, junction-path
vserver volume size state junction-path available used type
------- ----------------- ---- ------ ------------------ --------- ------- ----
SVM vol_recovery_test 16GB online /vol_recovery_test 5.08GB 10.12GB RW
何事もなくリカバリーできました。
階層化ポリシーと各階層の使用量を確認します。
# 階層化ポリシーの確認
::> volume show -vserver SVM -volume vol_recovery_test -fields tiering-policy
vserver volume tiering-policy
------- ----------------- --------------
SVM vol_recovery_test all
# 各階層の使用量の確認
::> volume show-footprint -vserver SVM -volume vol_recovery_test
Vserver: SVM
Volume Name: vol_recovery_test
Volume MSID: 2156877944
Volume DSID: 1098
Vserver UUID: 49892dec-8ccc-11ed-946a-5191ab1a5297
Aggregate Name: aggr1
Aggregate UUID: b7e5d9c9-8ccb-11ed-946a-5191ab1a5297
Hostname: FsxId05f72eb8f8d03c709-01
Tape Backup Metadata Footprint: -
Tape Backup Metadata Footprint Percent: -
Deduplication Footprint: 60.13MB
Deduplication Footprint Percent: 0%
Temporary Deduplication Footprint: -
Temporary Deduplication Footprint Percent: -
Cross Volume Deduplication Footprint: -
Cross Volume Deduplication Footprint Percent: -
Cross Volume Temporary Deduplication Footprint: -
Cross Volume Temporary Deduplication Footprint Percent: -
Volume Data Footprint: 10.18GB
Volume Data Footprint Percent: 1%
Flexible Volume Metadata Footprint: 92.66MB
Flexible Volume Metadata Footprint Percent: 0%
Delayed Free Blocks: 159.3MB
Delayed Free Blocks Percent: 0%
SnapMirror Destination Footprint: -
SnapMirror Destination Footprint Percent: -
Volume Guarantee: 0B
Volume Guarantee Percent: 0%
File Operation Metadata: -
File Operation Metadata Percent: -
Total Footprint: 10.49GB
Total Footprint Percent: 1%
Containing Aggregate Size: 907.1GB
Name for bin0: Performance Tier
Volume Footprint for bin0: 348.8MB
Volume Footprint bin0 Percent: 3%
Name for bin1: FSxFabricpoolObjectStore
Volume Footprint for bin1: 10GB
Volume Footprint bin1 Percent: 97%
Total Deduplication Footprint: 60.13MB
Total Deduplication Footprint Percent: 0%
Footprint Data Reduction by Auto Adaptive Compression: 3.11MB
Footprint Data Reduction by Auto Adaptive Compression Percent: 0%
Total Footprint Data Reduction: 3.11MB
Total Footprint Data Reduction Percent: 0%
Effective Total after Footprint Data Reduction: 10.49GB
Effective Total after Footprint Data Reduction Percent: 1%
こちらもリカバリー前後と比較して変わりありません。階層化ポリシーがAllでも安心してリカバリーできますね。
リカバリーキュー内のボリュームの削除
SSDの空き容量を確保するためにリカバリーキュー内のボリュームを削除したい時があると思います。
もちろん、そのような操作も可能です。
1つのボリュームを削除したい場合はvolume recovery-queue purgeで、リカバリーキュー内の全てのボリュームを全て削除したい場合はvolume recovery-queue purge-allで行えます。
実際にvolume recovery-queue purgeを試してみます。
まず、ボリュームを削除します。
# ボリュームをオフラインに変更
::> volume offline -vserver SVM -volume vol_recovery_test
Warning: Volume "vol_recovery_test" on Vserver "SVM" must be unmounted before being taken offline or restricted.
Clients will not be able to access the affected volume and related junction paths after that. Do you still
want to unmount the volume and continue? {y|n}: y
Volume "SVM:vol_recovery_test" is now offline.
# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test
Info: Volume "vol_recovery_test" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
The space used by the volume will be recovered only after the retention period of 12 hours has completed. To
recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
vol_recovery_test_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
<volume_name>" command.
Warning: Are you sure you want to delete volume "vol_recovery_test" in Vserver "SVM" ? {y|n}: y
[Job 1359] Job succeeded: Successful
ボリューム削除後、リカバリーキュー内のボリュームを削除します。
# 権限レベルを advanced に変更
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
# ボリュームリカバリーキューの確認
::*> volume recovery-queue show
Vserver Volume Deletion Request Time Retention Hours
--------- ----------- ------------------------ ---------------
SVM vol_recovery_test_1098
Fri Mar 31 17:50:59 2023 12
# リカバリーキュー内のボリュームの削除
::*> volume recovery-queue purge -vserver SVM -volume vol_recovery_test_1098
[Job 1361] Job succeeded: Successful
# リカバリーキュー内のボリュームが削除されたことを確認
::*> volume recovery-queue show
This table is currently empty.
リカバリーキュー内のボリュームが削除されましたね。削除時に特に警告はないようです。
削除後、SSDの空き容量とSSDとキャパシティプールストレージの使用量の確認します。
# 権限レベルを admin に変更
::*> set admin
# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
Available
Vserver Aggregate State Size Type SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM aggr1 online 798.1GB ssd non-snaplock
# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 62.32GB 7%
Aggregate Metadata 1.41GB 0%
Snapshot Reserve 45.36GB 5%
Total Used 109.0GB 12%
Total Physical Used 68.29GB 8%
Total Provisioned Space 100.1TB
11301%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 867.6MB -
Logical Referenced Capacity 867.6MB -
Logical Unreferenced Capacity 0B -
Total Physical Used 867.6MB -
2 entries were displayed.
階層化ポリシーがAllのボリュームを削除したのでSSDの変化は分かりづらいですが、キャパシティプールストレージの使用量が10.93GBから867.6MBと大きく減っていることが分かります。
ボリュームを削除してSSDの空きを確保したい場合に役立ちそうですね。
リカバリーキューの保持期間の変更
場合によってはリカバリーキューの保持期間を12時間から変更したい場面もあると思います。
そのような場合はvserver modifyの-volume-delete-retention-hoursで指定します。
こちらのオプションを指定する場合は権限レベルがdiagnosticである必要があります。
# advanced だと -volume-delete-retention-hours が指定できないことを確認
::*> vserver modify ?
[-vserver] <vserver name> Vserver
[ -language <language_code> ] Default Volume Language Code
[ -snapshot-policy <snapshot policy> ] Snapshot Policy
[ -comment <text (size 0..255)> ] Comment
[ -quota-policy <text (size 1..32)> ] Quota Policy
[ -aggr-list <aggregate name>, ... ] List of Aggregates Assigned
[ -max-volumes {<integer>|unlimited} ] Limit on Maximum Number of Volumes allowed
[ -admin-state {running|stopped|starting|stopping} ] *Vserver Admin State
[ -allowed-protocols {nfs|cifs|fcp|iscsi|ndmp|nvme}, ... ] Allowed Protocols
[ -disallowed-protocols {nfs|cifs|fcp|iscsi|ndmp|nvme}, ... ] Disallowed Protocols
[ -qos-policy-group <text> ] QoS Policy Group
[ -caching-policy <text> ] Caching Policy Name
[ -is-space-reporting-logical {true|false} ] Logical Space Reporting
[ -is-space-enforcement-logical {true|false} ] Logical Space Enforcement
[ -anti-ransomware-default-volume-state {disabled|dry-run} ] Default Anti_ransomware State of the Vserver\'s Volumes
::*> set diag
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y
# diagnostic だと -volume-delete-retention-hours が指定できることを確認
::*> vserver modify ?
[-vserver] <vserver name> Vserver
[ -language <language_code> ] Default Volume Language Code
[ -snapshot-policy <snapshot policy> ] Snapshot Policy
[ -comment <text (size 0..255)> ] Comment
[ -quota-policy <text (size 1..32)> ] Quota Policy
[ -aggr-list <aggregate name>, ... ] List of Aggregates Assigned
[ -max-volumes {<integer>|unlimited} ] Limit on Maximum Number of Volumes allowed
[ -admin-state {running|stopped|starting|stopping} ] *Vserver Admin State
[ -allowed-protocols {nfs|cifs|fcp|iscsi|ndmp|nvme}, ... ] Allowed Protocols
[ -disallowed-protocols {nfs|cifs|fcp|iscsi|ndmp|nvme}, ... ] Disallowed Protocols
[ -qos-policy-group <text> ] QoS Policy Group
[ -caching-policy <text> ] Caching Policy Name
[ -volume-delete-retention-hours <integer> ] *Volume Delete Retention Period
[ -is-space-reporting-logical {true|false} ] Logical Space Reporting
[ -is-space-enforcement-logical {true|false} ] Logical Space Enforcement
[ -anti-ransomware-default-volume-state {disabled|dry-run} ] Default Anti_ransomware State of the Vserver\'s Volumes
diagnosticは非常に強い権限です。そのため、NetAppのKBで紹介されている通り、NetAppのサポートがない限り使用してはいけません。
テクニカルサポートケースまたはプロフェッショナルサービス契約を通じてネットアップと連携 ネットアップのサポートがないかぎり、diagnostic権限レベルは絶対に設定しないでください
試しにリカバリーキューの保持期間を12時間から24時間に変更します。
# 現在のリカバリーキューの保持期間の確認 ::*> vserver show -vserver SVM -fields volume-delete-retention-hours vserver volume-delete-retention-hours ------- ----------------------------- SVM 12 # リカバリーキューの保持期間を24時間に変更 ::*> vserver modify -vserver SVM -volume-delete-retention-hours 24 # リカバリーキューの保持期間を24時間に変更されたことを確認 ::*> vserver show -vserver SVM -fields volume-delete-retention-hours vserver volume-delete-retention-hours ------- ----------------------------- SVM 24
本当にリカバリーキューの保持期間が24時間になっているかリカバリーキュー内のボリュームを確認します。
まず、適当なボリュームを作成して削除して確認します。
# 権限レベルを admin に変更
::*> set admin
# ボリュームの作成
::> volume create -vserver SVM -volume vol_recovery_test_3 -aggregate aggr1 -size 16GB -state offline
Storage efficiency cannot be enabled on the volume "vol_recovery_test_3" of vserver "SVM" because the volume state is "offline". Bring the volume online, and then enable storage efficiency using the "volume efficiency modify" command.
[Job 1365] Job succeeded: Successful
# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test_3
Info: Volume "vol_recovery_test_3" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
The space used by the volume will be recovered only after the retention period of 24 hours has completed. To
recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
vol_recovery_test_3_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
<volume_name>" command.
Warning: Are you sure you want to delete volume "vol_recovery_test_3" in Vserver "SVM" ? {y|n}: y
[Job 1367] Job succeeded: Successful
ボリューム削除後、リカバリーキューを確認します。
# 権限レベルを advanced に変更
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
# リカバリーキューの確認
::*> volume recovery-queue show
Vserver Volume Deletion Request Time Retention Hours
--------- ----------- ------------------------ ---------------
SVM vol_recovery_test_3_1100
Fri Mar 31 18:16:53 2023 24
リカバリーキュー内のボリュームのRetention Hoursが24になりましたね。
ちなみに、volume-delete-retention-hoursを0に指定すると、リカバリーキューに保持されず、即座にボリュームが削除されます。0を指定しないように注意してください。
リカバリキューを無効にします
volume-delete-retention-hoursがゼロに設定されている場合、この機能はその SVM に対して無効になります。その後のボリューム削除要求では、ボリュームが完全に破棄され、ボリュームはリカバリキューに保持されません。この機能を無効にすることはお勧めしません。
::*> vserver modify -vserver <vserver_name> -volume-delete-retention-hours 0
リカバリーキュー内のボリュームの保持期間の変更
vserver modifyの-volume-delete-retention-hoursで指定した値は、既にリカバリーキュー内にあるボリュームの保持期間に影響を与えません。
リカバリーキュー内のボリュームの保持期間の変更したい場合は、volume recovery-queue modifyを実行します。
試しに現在リカバリーキュー内にあるボリュームの保持期間を24時間から１時間に変更します。
::*> volume recovery-queue modify -vserver SVM -volume vol_recovery_test_3_1100 -retention-hours 1
::*> volume recovery-queue show
Vserver Volume Deletion Request Time Retention Hours
--------- ----------- ------------------------ ---------------
SVM vol_recovery_test_3_1100
Fri Mar 31 18:16:53 2023 1
リカバリーキュー内のボリュームの保持期間を取り敢えず延長したい場合に役立ちそうです。
ボリューム削除時に -force を指定する
NetAppのKBを眺めていると、リカバリーキューの保持期間が経過していないにも関わらず、ボリュームが削除されることがあるようです。
どうやら、ボリューム削除時に-forceを付与すると、そのような挙動をするようです。
試してみましょう。
# ボリュームの作成
::> volume create -vserver SVM -volume vol_recovery_test_4 -aggregate aggr1 -size 16GB -state offline
Storage efficiency cannot be enabled on the volume "vol_recovery_test_4" of vserver "SVM" because the volume state is "offline". Bring the volume online, and then enable storage efficiency using the "volume efficiency modify" command.
[Job 1370] Job succeeded: Successful
# -force を指定できるか確認
::> volume delete -vserver SVM -volume vol_recovery_test_4 -?
[ -foreground {true|false} ] Foreground Process (default: true)
# 権限レベルを advanced に変更
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
# -force を指定できることを確認
::*> volume delete -vserver SVM -volume vol_recovery_test_4 -?
[[-force] [true]] *Force Delete
[ -foreground {true|false} ] Foreground Process (default: true)
# -force を指定してボリュームを削除
::*> volume delete -vserver SVM -volume vol_recovery_test_4 -force
[Job 1372] Job succeeded: Successful
この状態でリカバリーキューを確認します。
::*> volume recovery-queue show
Vserver Volume Deletion Request Time Retention Hours
--------- ----------- ------------------------ ---------------
SVM vol_recovery_test_3_1100
Fri Mar 31 18:16:53 2023 1
確かに削除したボリュームvol_recovery_test_4がリカバリーキューに存在していないですね。
FlexGroupボリュームのリカバリー
FlexGroupボリュームもリカバリーキューからリカバリーできるか確認しておきます。
適当にFlexGroupボリュームを作成します。
# FlexGroupボリュームを作成
::> volume create -vserver SVM -volume vol_recovery_test_5 -aggr-list aggr1 -aggr-list-multiplier 4 -size 16GB
Notice: The FlexGroup volume "vol_recovery_test_5" will be created with the following number of constituents of size
4GB: 4.
Warning: The constituent size is smaller than the recommended minimum constituent size of 100GB. You should ensure that
the size of a 4 constituent FlexGroup volume be at least 400GB (429496729600B), or the performance of the
FlexGroup volume will be less than optimal.
Do you want to continue? {y|n}: y
Warning: You are attempting to create a FlexGroup volume in Vserver "SVM", which currently uses 32-bit NFSv3 FSIDs and
file IDs. This could result in collisions between different file IDs on the FlexGroup volume. Modify the
Vserver to use 64-bit NFSv3 identifiers before using the FlexGroup volume with the commands "set advanced;
vserver nfs modify -vserver SVM -v3-64bit-identifiers enabled".
Do you want to continue? {y|n}: y
[Job 1374] Job succeeded: Successful
# FlexGroupボリュームの確認
::> volume show -vserver SVM -volume vol_recovery_test_5*
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM vol_recovery_test_5
- online RW 16GB 14.98GB 1%
# FlexGroupボリュームのメンバーボリュームの確認
::> volume show -vserver SVM -volume vol_recovery_test_5* -is-constituent true
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM vol_recovery_test_5__0001
aggr1 online RW 4GB 3.74GB 1%
SVM vol_recovery_test_5__0002
aggr1 online RW 4GB 3.74GB 1%
SVM vol_recovery_test_5__0003
aggr1 online RW 4GB 3.74GB 1%
SVM vol_recovery_test_5__0004
aggr1 online RW 4GB 3.74GB 1%
4 entries were displayed.
FlexGroupボリュームを削除します。
# ボリュームをオフラインに
::> volume offline -vserver SVM -volume vol_recovery_test_5
Volume "SVM:vol_recovery_test_5" is now offline.
# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test_5
Info: Volume "vol_recovery_test_5" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
The space used by the volume will be recovered only after the retention period of 24 hours has completed. To
recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
vol_recovery_test_5_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
<volume_name>" command.
Warning: Are you sure you want to delete volume "vol_recovery_test_5" in Vserver "SVM" ? {y|n}: y
[Job 1379] Job succeeded: Successful
# ボリュームが削除されたことを確認
::> volume show -vserver SVM -volume vol_recovery_test_5* -is-constituent true
There are no entries matching your query.
ボリュームが削除されましたね。
リカバリーキューを確認して、FlexGroupボリュームをリカバリーします。
# 権限レベルを advanced に変更
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
# ボリュームリカバリーキューの確認
::*> volume recovery-queue show
Vserver Volume Deletion Request Time Retention Hours
--------- ----------- ------------------------ ---------------
SVM vol_recovery_test_3_1100
Fri Mar 31 18:16:53 2023 1
SVM vol_recovery_test_5_2156877948
Fri Mar 31 19:40:20 2023 24
2 entries were displayed.
# FlexGroupボリュームのリカバリー
FsxId05f72eb8f8d03c709::*> volume recovery-queue recover -vserver SVM -volume vol_recovery_test_5_2156877948
Notice: When you bring a recovered volume online, there may be a temporary drop in performance for all volumes in the same aggregate.
Volume recovery successful for volume "vol_recovery_test_5_2156877948" in Vserver "SVM".
# 権限レベルを admin に変更
FsxId05f72eb8f8d03c709::*> set admin
# ボリュームがリカバリーされていることを確認
FsxId05f72eb8f8d03c709::> volume show -vserver SVM -volume vol_recovery_test_5* -is-constituent true
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM vol_recovery_test_5_2156877948__0001
aggr1 offline RW 4GB - -
SVM vol_recovery_test_5_2156877948__0002
aggr1 offline RW 4GB - -
SVM vol_recovery_test_5_2156877948__0003
aggr1 offline RW 4GB - -
SVM vol_recovery_test_5_2156877948__0004
aggr1 offline RW 4GB - -
4 entries were displayed.
::> volume show -vserver SVM -volume vol_recovery_test_5*
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM vol_recovery_test_5_2156877948
- offline RW 16GB - -
# ボリュームの名前変更
::> volume rename -vserver SVM -volume vol_recovery_test_5_2156877948 -newname vol_recovery_test_5
[Job 1387] Job is queued: Rename vol_recovery_test_5_2156877948 to vol_recovery_test_5.
[Job 1387] Job succeeded: Successful
# ボリュームをオンラインに
::> volume online -vserver SVM -volume vol_recovery_test_5
Volume "SVM:vol_recovery_test_5" is now online.
FsxId05f72eb8f8d03c709::>
FsxId05f72eb8f8d03c709::> volume show -vserver SVM -volume vol_recovery_test_5*
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM vol_recovery_test_5
- online RW 16GB 15.03GB 1%
# ボリュームの状態を確認
::> volume show -vserver SVM -volume vol_recovery_test_5* -is-constituent true
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM vol_recovery_test_5__0001
aggr1 online RW 4GB 3.74GB 1%
SVM vol_recovery_test_5__0002
aggr1 online RW 4GB 3.74GB 1%
SVM vol_recovery_test_5__0003
aggr1 online RW 4GB 3.74GB 1%
SVM vol_recovery_test_5__0004
aggr1 online RW 4GB 3.74GB 1%
4 entries were displayed.
FlexGroup特有のポイントは特になく、すんなりとリカバリーできました。
ボリューム削除時にはボリュームリカバリーキューを意識しよう
Amazon FSx for NetApp ONTAPでボリュームリカバリーキューを使ってみました。
ボリュームを間違えて削除してしまった場合は、バックアップからリストアするよりも高速にリカバリーすることができます。
これはありがたいですね。
一方で、リカバリーキューがあることにより、ボリュームを削除しても即座にSSDが解放されないことに気をつける必要があります。その場合は十分注意した上でリカバリーキュー内のボリュームを削除しましょう。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[Amazon FSx for NetApp ONTAP] SMBでファイルオープン中にフェイルオーバーが発生した場合の挙動を確認してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
